home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
EnigmA Amiga Run 1996 February
/
EnigmA AMIGA RUN 04 (1996)(G.R. Edizioni)(IT)[!][issue 1996-02][Skylink CD III].iso
/
earcd
/
faq
/
fds-310.lha
/
FDS-310.examples
next >
Wrap
Text File
|
1995-10-25
|
15KB
|
378 lines
@Start_of_text
========================================================================
EXAMPLES EXAMPLES
========================================================================
1.0 DEFAULT DESCRIPTIONS
=========================
· Example 1.1
--- 8< -------------------------
%DES: Default
<Short description>
--- 8< -------------------------
This is *THE* simplest form of FDS description, which only contains one
single description line. The description in this case is the DEFAULT
description (the english description).
· Example 1.2
--- 8< -------------------------
%DES: Default
<Short description>
<Extended description, line 1>
<Extended description, line 2>
--- 8< -------------------------
This is the same as example 1.1, but with the addition of two lines for
the extended description. Please note again that you MUST ALWAYS have a
SHORT description. See also next example.
· Example 1.3
--- 8< -------------------------
%DES: Default
<Extended description, line 1>
<Extended description, line 2>
--- 8< -------------------------
This example description is a bit wrong. The first "extended" line
will be the SHORT description in this example. ALWAYS remember that the
very first line of the description text is used as a one-line
description.
· Example 1.4
--- 8< -------------------------
%DES: Default
<Short description>
<Extended description, line 1>
<Extended description, line 2>
$DES: Svenska
<Short SWEDISH description>
<Extended SWEDISH description, line 1>
<Extended SWEDISH description, line 2>
$AUT: John Doe
--- 8< -------------------------
This is a multi-language description, where the DEFAULT description
comes first. It also contains a Swedish description as well as an
author keyword informing you who the author is. See also example 1.5.
· Example 1.5
--- 8< -------------------------
%DES: Svenska
<Short SWEDISH description>
<Extended SWEDISH description, line 1>
<Extended SWEDISH description, line 2>
%AUT: John Doe
%DES: Default
<Short description>
<Extended description, line 1>
<Extended description, line 2>
--- 8< -------------------------
Here the default description have been moved to the end of the file,
but this is essentially exactly the same as example 1.4.
· Example 1.6
--- 8< -------------------------
%DES: Svenska
<Short SWEDISH description>
<Extended SWEDISH description, line 1>
<Extended SWEDISH description, line 2>
%AUT: John Doe
--- 8< -------------------------
Well, this description doesn't even have a default description. How
does that work then? Well, it is up to the parsing software to allow
the end-user to select if it should use some other description (in this
example, a swedish sysop will probably use the swedish description) or
if no description should be used at all (an Italian sysop would probably
NOT want to use the swedish description). I don't see this as a
limitation, but rather the opposite, and I believe that most
descriptions will use a default(english) description anyway, so...
2.0 SECTIONS IN EXTENDED DESCRIPTIONS
======================================
NOTE: The examples in this chapter will only show the extended
description, NOT the entire description file
This is the "template" used in this chapter;
--- 8< -------------------------
This is a test of how the use of sections in
the extended descriptions should be used.
This is the second section.
This is actually the fourth section, as the empty line
might be considered to be the third. This is not that
interesting for the end-user, but might be of help to
developers.
- This is a list
- of features, or
- a list of known
- bugs...
- Anyhow, this "list" is treated the same way as
- the above sections, and each of these lines
- is actually a section. This means that these
- lines are allowed to be wrapped to a defined
- linelength.
This is the last section to be used, but after this
section follows two empty lines, which would've been
considered to be valid sections if they hadn't been
AFTER the last "real" section (i.e. this section)
--- 8< -------------------------
Ok, I will try to explain what is supposed to happen with sections.
Each section is used in a way similar to chapters in a book. This means
that each section should not interfere with another, which also prevents
the wordwrap routine to "mix" sections.
· Example 2.1
First, let's take a look at the first two sections;
--- 8< -------------------------
This is a test of how the use of sections in
the extended descriptions should be used.
This is the second section.
--- 8< -------------------------
There is a difference between these two sections that might not be that
obvious. As you can see, the second section BEGINS with the space in
the first position on the row. The space in the first position always
mean that a new section begins there. Now, the first section doesn't
have this space on the first row, why is that? Well, being the first
section it does not NEED a space, because of it BEING the first row in
the extended description. Of course, it could have been a space there,
it would've meant the same thing. Note though that the OUTPUT of the
parser should put a space there, if there was no space there in the
first place.
· Example 2.2
Let's take a look at the "list" from the template.
--- 8< -------------------------
- This is a list
- of features, or
- a list of known
- bugs...
- Anyhow, this "list" is treated the same way as
- the above sections, and each of these lines
- is actually a section. This means that these
- lines are allowed to be wrapped to a defined
- linelength.
--- 8< -------------------------
As these lines begin with a space, they are all divided into separate
sections, which prevents them from being wrapped together into an
unreadable mess. BUT, each of these lines might be wrapped by itself,
IF the end-user specifys a linelength of LESS characters than one of
these lines are long. This will probably not be a big problem, but the
leading spaces (4 in this case) should remain as they are, i.e. they
should not be converted into ONE single space. For example; Wrapped for
35 chars width, the output should look like this:
|-------------- 35 ---------------|
- This is a list
- of features, or
- a list of known
- bugs...
- Anyhow, this "list" is
treated the same way as
- the above sections, and each
of these lines
- is actually a section. This
means that these
- lines are allowed to be
wrapped to a defined
- linelength.
|---------------------------------|
...which I admit, doesn't look very nice, but is the SIMPLE way to wrap
text. Developers might choose to do some really fancy stuff when it
comes to wordwrapping, but this is the way it should work as a minimum.
I mean, intelligent coding could produce the following instead of the
above;
|-------------- 35 ---------------|
- This is a list
- of features, or
- a list of known
- bugs...
- Anyhow, this "list" is
treated the same way as
- the above sections, and each
of these lines
- is actually a section. This
means that these
- lines are allowed to be
wrapped to a defined
- linelength.
|---------------------------------|
Well, the above examples might be a "worst-case-scenario", as most
boards allow descriptions 44 chars or MORE for descriptions. A tip
would be to keep any "lists" like the above one UNDER 45 chars in width.
· Example 2.3
Trailing "empty" sections.
In the very end of the template, the following sections can be found;
--- 8< -------------------------
This is the last section to be used, but after this
section follows two empty lines, which would've been
considered to be valid sections if they hadn't been
AFTER the last "real" section (i.e. this section)
--- 8< -------------------------
Actually, as I've mentioned before, the empty lines are sections too,
but as the two lines in the above example really are unnecessary, I
recommend that parsing software strips them from the output. Thus,
trailing "empty" sections should be removed from the OUTPUT of any
parsing software.
3.0 EXAMPLE DESCRIPTIONS
=========================
· Example 3.1
--- 8< -------------------------
%DES: Default
MouseTool 3.2, mouse utility.
Mouse accelerator, blanker, sound daemon
and more useful stuff.
%AUT: Steven Parkinson
%VER: MouseTool 3.2 (7.6.93)
%REV: 37.84
%DAT: 13.6.93
%REQ: Amiga, OS 2.04+
%OBJ: Mouse Utility Commodity
%LAN: Locale/English/Deutsch
%REP: MTOOL30.LHA MTOOL31.LHA
%END:
--- 8< -------------------------
Description with only DEFAULT (english) description consisting of a
SHORT description (first line) and two EXTENDED description (next two)
lines, author info, version, revision and release date. Program
requires an Amiga with at least OS 2.04, and supports any language
provided a translation is created. It's supplied with English built-in,
and German as an option. It has some search keyword attached, which
means that a BBS could easily categorize it to a proper area.
Furthermore, it supplies information on previous, obsolete, versions,
which could now be deleted.
· Example 3.2
--- 8< -------------------------
%DES: Default
GIF 800x600: Albert Einstein
%OBJ: Picture Graphics Painting
%FIL: Einstein.gif
--- 8< -------------------------
Another very simple description, containing only a SHORT description.
· Example 3.3
--- 8< -------------------------
%DES: Elite
.------------------------------------------.
| UFO Enemy unknown, Vitality fix! |
|------------------------------------------|
| How to get loads of cash |
| and awesome soldiers |
| UFO Enemy Unknown |
|------------------------------------------|
|Start the Game with 2.147.483.647 Credits.|
`------------------------------------------'
%DES: Default
UFO Enemy Unknown, vitality fix.
Get LOADS of money and supersoldiers
in this great game from MicroProse
%REQ: AGA Amiga, UFO Enemy Unknown
%OBJ: Game Cheat
%END:
--- 8< -------------------------
This description contains an "elite"-description, which could contain
some ASCII-art by any of the good ASCII-artists out there. This example
isn't very extreme but wouldn't have made a good description had it been
used as an ordinary description. This is where the %DES: Elite comes
into the picture, because it MUST NOT be wrapped, which in turn allows
these kinds of descriptions. There is also a DEFAULT description, which
follows the usual rules for the descriptions.
· Example 3.4
--- 8< -------------------------
%DES: Default
Spot 1.3, offline reader supreme
The best point-program available for the
Amiga. VERY user-friendly!
%AUT: Nico François
%VER: Spot 1.3 (16.8.94)
%REV: 37.4515
%REQ: Amiga 2.04+
%LAN: Locale/English/Dansk/Deutsch/Espanol/Francais/Italiano...
%TYP: Shareware, features disabled.
%REG: US$30, UK£20, 1000 BEF, 50 DM
--- 8< -------------------------
Well, this example is mainly to show the use of the %TYP: and %REG:
keywords, which can be used to describe if the software is crippled in
any way, and how much it costs to register. Spot, in this case, is
Shareware, and some features are disabled in the unregistered version.
Other softwares/authors might be Freeware, Cardware, Giftware, Mailware,
Callware or whatever... Use it if you want to...:)
4.0 NOTES ON EXAMPLES
======================
Well, it's not that easy for me, knowing the standard inside out,
writing things I THINK you might be uncertain of, so if there is
something that needs more explaining, please tell me, and I will add
more examples. OR, if you want to, send me more examples yourself!
- Peter
@End_of_text